This PR introduces a new sensitive flag for tools in the MCP specification. With this update, tools can now indicate if they perform sensitive operations that require explicit user confirmation before invocation. The change is applied across the documentation and the JSON schema, as well as the TypeScript definitions.

Motivation and Context

The motivation behind this update is to enhance security and trust when tools are invoked. By marking a tool as sensitive, clients can be alerted to always present a confirmation prompt to the user. This helps mitigate risks associated with sensitive operations by ensuring a human is in the loop before any critical action is performed.

How Has This Been Tested?

Since this change is a non-breaking update to the specification and only affects the documentation and schema definitions, no runtime tests were necessary.

Breaking Changes

This change is non-breaking:
• Existing tools without the sensitive flag will continue to operate with the default behavior (i.e., treated as non-sensitive).
• Clients may choose to leverage the new flag to enforce additional UI confirmation, but backward compatibility is maintained.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

At Crunchloop, we are implementing MCP servers to enable our customers’ internal teams to interact with their custom platforms both efficiently and safely. A common concern that arises is how to incorporate a non-deterministic check that requires explicit operator confirmation before executing a given tool. While our current solution uses a carefully crafted system prompt to inform the LLM about the necessary security measures, the inherent non-determinism of LLMs sometimes falls short in ensuring that sensitive operations receive the proper human confirmation. With the new sensitive flag, we provide a clear, protocol-level signal that mandates explicit confirmation for sensitive operations, thereby reinforcing safety and reducing reliance on LLM behavior alone.

While researching similar discussions, I discovered a previous discussion on this topic (Discussion #71) that, despite its relevance, didn’t gain significant traction. Initially, I considered introducing a confirmation flag to address the issue. However, after further reflection, I decided that a sensitive flag better conveys the intent by explicitly indicating when a tool performs operations that require heightened security measures.